Field of the Invention
The disclosed methods and systems related generally to securing resources and privileges on a computer, and more particularly to controlling access to resources and controlling privileges per process.
Background Information
A user logs on to a computer locally by giving his user name and password to the operating system (“OS”). The OS then creates a logon session and an access token for that user. The access token includes a unique identifier (i.e., known as a security ID (“SID”) for the logged-on user), a list of privileges the user has or the user's groups has, and a list of all the groups to which the user, as identified by his/her unique SID, belongs. Each group is also identified by a unique SID. For each process that is created during the logon session, the OS assigns a copy of the original access token to that process. A token assigned to a process is a process token. An example of a process token is shown in FIG. 1.
A user's membership in different groups determines what securable objects the user is able to access, presuming the object allows members of that group access. A securable object includes, but is not limited to, a file, process, event, or anything else having a security descriptor. For example, a user will not be able to access a securable object if access to that securable object, is limited to a group of which the user is not a member. Similarly, a user's privileges are limited to those associated with the access token.
Whenever a process tries to access a securable object, the OS performs an access check. The OS compares the process token to an access control list (“ACL”) of the securable object. An access control list is a list of security protections that applies to the securable object. An entry in an ACL is known as an access control entry (“ACE”). An ACE contains a set of access rights, such as read/write, etc., and a SID that identifies a group and/or user for whom the rights are allowed, denied, or audited. If the SID in the process token matches an SID in the ACL of the securable object, and if the ACE (for that SID) rights are set to “allow,” then the process associated with the process token will be able to access the securable object. Otherwise, the process will be denied access to the securable object.
Access to the securable object may also be denied if, for example, within the ACE of that SID, rights are set to “deny,” even if the process token contains a copy of the SID that is in the securable object's ACL.
It is also possible that some privileges instruct the OS to bypass the securable object's ACL. Under such a security arrangement, each process created by the OS in response to a given process's request therefore has the same token as the requesting process, and thus share the same access to securable objects and privileges.
Situations may arise, however, where, in order to perform a task, a user needs access to securable objects and/or privileges that are outside the scope of his current group membership and/or privileges listed in the user's access token. One solution to this problem is to make the user a member of a group that has expanded access and/or privileges, such as the Administrators Group in a Windows-brand OS. This solution may have unintended consequences, as the user gains not only the needed access and/or privilege(s), but greater access and other privileges as well. Making the user a member of the Administrators Group enables the user to access the particular needed object, but may also enable the user to install unauthorized applications, perform unauthorized modifications to the configuration of their computer, and so on. Potentially even more importantly, users with elevated privileges and access are more vulnerable to malware (e.g., viruses, trojans, worms, and the like) which may threaten the user's computer, the user's account, shared accounts, and the network. Thus, a means of granting only needed access and/or privileges is desirable.
In MICROSOFT™ WINDOWS™, a Group Policy Object (GPO) is a collection or grouping of configuration settings that are applied to computers automatically. Group Policy is a MICROSOFT™ implementation of the general concept of policy-based management, which is a computer management model. One potential implementation of a group policy system is described in U.S. Pat. No. 6,466,932. By applying the configuration settings to the computers, a system administrator or other entity may define and set the behavior and appearance or configuration of the computers. Accordingly, a GPO is generally configured by a system administrator or other high-level administrator, and as an object, a GPO can be associated with a hierarchical grouping known as a “container.” A container may be a domain, a site, an organization unit (OU), or other association of computers, systems, or users. In some example instances, a GPO may define script options, security options, software-installation options, folder-redirection options, software-maintenance options, and other configuration options.
Each GPO has a list that controls whether the GPO's settings are applied to given users, groups, and/or computers. An entity that is on the list has the GPO's settings applied to it. An entity not on the list does not have the GPO's settings applied to it. The use of groups, as opposed to user or computer identities, as the criterion on which the settings application decision is made may be referred to as GPO-level filtering. Accordingly, GPO-level filtering allows a system administrator to specify whether a GPO is applied or denied to users or computers. The GPO is thus applied in its entirety, or denied in its entirety, to a user, computer, or system.
In a MICROSOFT™ implementation, GPOs are populated with settings by a Group Policy Object Editor (GPOE). Settings are applied on client computers by corresponding extensions, called Client-Side Extensions (CSEs). There is a documented extension model that MICROSOFT™ provides for software vendors to extend these systems and, by doing so, provide new functionality within the WINDOWS™ Group Policy architecture.